The proliferation of data transport networks, most notably the Internet, is causing a revolution in telephony and other forms of real-time communication. Businesses that have been accustomed to having telephony traffic and data traffic separately supported over different systems and networks are now moving towards so-called “converged networks” wherein telephone voice traffic and other forms of real-time media are converted into digital form and carried by a packet data network along with other forms of data. Now that the technologies are feasible to support it, voice over data transport offers many advantages in terms of reduced capital and operating costs, resource efficiency, and flexibility.
For example, at commercial installations, customer premise equipment investments are substantially reduced as most of the enhanced functions, such as Private Branch Exchange (PBX) and automatic call distribution functions, may reside in a service provider's network. Various types of gateways allow for sessions to be established even among diverse systems, such as IP phones, conventional analog phones and PBXs, as well as with networked desktop computers.
To meet the demand for voice over data transport, service providers and network equipment vendors are faced with the challenges of establishing new protocols and standards, recognizing new business models, implementing new services, and designing new equipment in a way that would have been difficult to imagine twenty years ago.
For example, a new generation of end user terminal devices are now replacing the traditional telephones and even the more recent PBX phone sets. These new sets, such as those offered by CISCO SYSTEMS, Inc. and PINGTEL Corporation, may connect directly to a common packet data network, via an Ethernet connection for example, and feature large visual displays to enhance the richness of the user interface.
Even before such devices were developed, computers equipped with audio adapters and connected to the Internet were able to conduct some rudimentary form of Internet telephony, although the quality was unpredictable and often very poor. The emphasis now is upon adapting Internet Protocol (IP) networks and other packet transport networks to provide reliable toll-quality connections, easy call set-up and enhanced features to supply full-featured telephony as well as other forms of media transport. Some other types of media sessions enabled by such techniques may include video, high quality audio, multi-party conferencing, messaging, and collaborative applications.
Of course, as a business or residential communications subscriber begins using such voice-over-packet communications to replace conventional telephony, there will naturally be an expectation that the quality of the connections and the variety of services will be at least as good as in the former telephone network. In terms of services, for example, some businesses have come to rely upon PBX features or network-resident “Centrex” features such as call forwarding and conditional call handling. In the near future, such special services are expected to see increased use because the new terminal devices mentioned earlier can provide a much more intuitive interface for the users. With existing systems, users often forget which combinations of keystrokes are required to invoke enhanced features.
For establishing a communications session in a network, new protocols and control architectures have emerged. It is worth noting that these have been inspired by the migration to a voice over data, but are not necessarily limited to such an environment. In some respects the protocols and control architectures described next may be used to establish calls through any form of transport.
One example of an approach for establishing a communications session among terminals connected to a network is the H.323 set of standards promulgated by the ITU (International Telecommunications Union). Another example is the Session Initiation Protocol (SIP) put forth by the IETF (Internet Engineering Task Force). The SIP protocol is described in IETF document RFC 2543 and its successors. Various architectures have been proposed in conjunction with these protocols with a common theme of having an address resolution function, referred to as a “location server,” somewhere in the network to maintain current information on how to reach any destination and to control features on behalf of users.
For large scale-deployment of voice over data transport as well as other real-time communications, it is essential that the network control architectures be extremely robust and highly scalable to reliably accommodate millions of sessions on a daily basis. Robustness may necessitate designing in redundancy and failover mechanisms. Preferably, these measures will even provide transparent continuity of existing sessions and features even if a failure occurs in the midst of a session. For ensuring this level of reliability and for maximizing scalability, it is generally preferable to minimize the demand upon control functions, such as location servers, to maintain any persistent state information for each call in the network. Consequently, many of the control and signaling communications for accomplishing network services are designed to be self-contained, meaning that they carry sufficient context information to avoid relying upon state persistence in the servers handling the messages.
The integration of voice and data services relies on the capability to interface different communications systems, particular those systems that have been traditionally strictly telephony-orient or strictly data communications oriented. One approach is to deploy gateways to provide such a capability. In the context of real-time communications, a gateway is generally a device that adapts signaling and media-bearing channels from one type of network to another type.
A good example of this function is a so-called “network gateway” which adapts a packet telephony network to a Public Switched Telephone Network (PSTN). At least two aspects of adaptation must take place. For signaling, the Signaling System 7 (SS7) or similar signaling employed in the PSTN must be mapped to SIP or similar messaging in the packet network so that the two networks can cooperatively establish a connection. For the media or bearer channel, the analog or Pulse Code Modulation (PCM)-encoded voice signals need to be converted into packetized data amenable to the packet transport network.
Another type of gateway is the so-called “DAL gateway”. A DAL (Dedicated Access Line) is commonly known in traditional telephony as a means for a communications customer, such as a business enterprise, to connect directly to a core telephony switch, such as a Class 3 switch, through a trunk line. A DAL connection may be viewed as bypassing a Class 5 end-office switch, which is more suitable for serving individual (residential) subscriber loops. A DAL is often used to support customers of VPN (Virtual Private Network) services having large numbers of phones and numerous sites. Large business customers often have PBX's which couple to the Class 3 switch network through T1 lines or the like. VPN customers have private dialing plans, that is, dialing prefixes that are independent of the geographically-based exchange prefixes used in the public telephone network.
As described herein, a DAL gateway is a device whereby a user who is not at a location directly served by VPN services may nevertheless reach the VPN facilities and dial according to the VPN dialing plan. For example, an employee of a large company may be familiar with the internal telephone numbers of other employees at other sites around the country. When away from the VPN-served workplace, the employee may use a conventional phone in the PSTN network to reach the VPN and place calls within the company using the internal company dialing plan. This is accomplished by dialing a special telephone number to reach the gateway and entering an authorization code and a VPN-context destination telephone number, whereupon the gateway will patch the call through the VPN to the desired party. This is especially helpful for avoiding personal long distance charges that would otherwise be incurred by the employee if they dialed remote destinations through the PSTN rather than the VPN.
As business enterprises migrate to packet telephony, there is a need to provide VPN services and, more particularly, to provide for access to VPN services from outside the packet-switched VPN environment. A DAL gateway must therefore accept calls from a conventional telephone network and connect these calls to destinations in the packet-switched using an appropriate dial plan to interpret the dialed number.
FIG. 6 is a diagram of a conventional approach wherein multiple DAL gateways are used to service multiple enterprise customers. In system 600, a number of gateways 601, 603, 605 interface to a network 609 comprising telephone switches, exemplified by Class 3 switch 607. Switch 607 provides multiple DAL trunks corresponding to multiple Private Branch Exchanges (PBXs) 617, 619, 621. Each of these private telephone networks 617, 619, 621 may be representative of enterprises having VPN services provided through network 609 and data network 627. Each such enterprise may employ private numbering plans within their respective network configurations. Routing of calls within an enterprise is performed in the context of the particular dialing plan. Accordingly, it is acceptable for different enterprises to have some identical internal telephone numbers because these will actually be routed differently based on the respective enterprise dialing plans.
Class 3 networks, such as the network 609, commonly use two different types of routing. One form of routing is based on explicitly specifying the destination switch ID (identification) and trunk-group. The other is based upon the number as dialed by an originator, followed by a table look-up or other logic to resolve the dialed number to a switch/trunk destination.
In FIG. 6, a SIP server 631 is coupled to gateways 601, 603, 605 through data network 627. SIP server 631 mediates the establishment of communications sessions through data network 627. In particular, SIP server 631 handles request for sessions by first determining the data network addresses of points that need to communicate and then coordinating the establishment of communications between the selected points.
When a DAL gateway (e.g., 601, 603, and 605) receives a call or communications request from a calling party, such as phone 623, SIP server 631 receives a corresponding session request from the gateway to which the call was placed.
For example, assume phone 623, PBX 617, gateway 601, and SIP client 626 are all associated with the same VPN used by Company A. A caller 624 using phone 623 might try to reach SIP client 626 by dialing “222-5723”. To set up the call, PBX 617 would signal to switch 607 which, based upon the identity of trunk 611, would route the call to gateway 601. Recognizing the inbound call, gateway 601 would send a SIP INVITE message, or the like, through network 627 to SIP server 631.
The address of gateway 601, which is a unique address in the realm of data network 627, would be conveyed as part of the SIP INVITE message, allowing SIP server 631 to determine which VPN-dedicated DAL gateway the call arrived through and, hence, which dialing plan to use in interpreting the dialed number and routing the call. In this case, SIP server 631 would retrieve the dial plan to determine the address of SIP client 626 as corresponding to dialed number “222-5723”. To carry the actual conversation, a media session would then be established through data network 627 and be coupled through gateway 601 to a telephone channel through switch 607 and PBX 617.
Likewise, as similar sequence of events would occur if caller 629 at a second enterprise, Company B, used phone 628 to reach SIP client 625 through PBX 619, switch 607, gateway 603, and SIP server 631. It is especially important to note caller 629 might even use the same dialed number to reach SIP Client 625 that caller 624 used to reach SIP client 626, the difference being the dial plan context.
By virtue of the dialing plan context being established, it is even possible for an ordinary PSTN phone 632 to be used by either caller 624 or caller 629 to reach their respective counterparts. In this scenario, a caller 624 uses phone 632 to dial a special access number, such as a particular toll-free number, to reach gateway 601. This telephone call will be routed in the conventional manner by Class 5 end-office switch 630 and Class 3 switch 607. Upon being connected to gateway 601, the caller will be prompted by the gateway to provide authentication information and to enter the number of the party that is to be reached, namely “222-5723” to reach SIP client 626.
Caller 629 may also use phone 632, which may be a public pay phone or hotel phone, for example, to reach SIP client 625. Caller 629 first dials a special access number that is different than the one caller 624 used earlier. This access number results in the call from phone 632 being routed to gateway 603 where a similar interaction takes place to obtain the authentication and destination number information.
Thus, call requests for different companies come through different gateways. SIP server 631 determines which set of routing rules to apply, that of Company A or Company B, based upon which gateway's network address appears in the incoming INVITE request. Under this approach, each gateway is mapped to one set of customer routing rules in SIP server 631. Accordingly, calls from the switch 607 are separated according to the customers into separate gateways 601, 603, 605. As noted above, multiple gateways 601, 603, 605 are needed because each gateway 601, 603, 605 possesses a unique host address, thereby permitting the SIP server 625 to discern the particular routing rules to apply—in which the selection of these rules depends on the particular gateway.
Under this conventional arrangement, a number of drawbacks arise. First, scaling is problematic, in that a gateway is required for each individual customer to ensure proper routing of calls. Significant cost is thus incurred under this architecture, thereby reducing the competitiveness of the service provider. Further, this conventional approach is inefficient, as a gateway is constrained to one set of routing rules.
Therefore, there is a need for an approach for efficiently performing telephony services over a data communications system. Additionally, there is a need to enhance scalability. There is also a need to preserve a standard architecture to promote deployment of network services, while minimizing system complexity. There is a further need to reduce administration and operational costs.